Rules-based deployment of computing components

ABSTRACT

A system and method deploys components such as computer programs on one or more of computing devices such as servers in a server farm. A deployment system communicates with the computing devices over a computer network. As a result, a data set is received for each computing device and the data set contains information indicative of characteristics of the computing devices. Computer-executable instructions capable of comparing characteristics of the at least one computing device to a set of predefined characteristic constraints are executed to determine whether the computing device meets predefined installation rules. Installation proceeds if the characteristics meet the predefined characteristic constraints.

CROSS REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. Provisional ApplicationNo. 60/455,749, filed Mar. 19, 2003, “Discovery and Analysis of Systemand Database Inventories for Server Consolidation,” which is herebyincorporated by reference in its entirety.

COPYRIGHT NOTICE AND PERMISSION

A portion of the disclosure of this patent document may contain materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever. The following notice shall apply to this document:Copyright © 2004, Unisys Corp.

FIELD OF THE INVENTION

The present invention relates to the field of computing systems and,more specifically, to systems and methods for server consolidation.BACKGROUND OF THE INVENTION

04 As technology has become more prevalent in business organizations,organizations have created server farms in an ad hoc fashion. Forinstance, as a new application become available or needed, organizationsoften add a new server to provide the computing support for thatapplication. Often times, the server would have enough computing poweronly to run that particular application. Such ad hoc server farms becomean unwieldy combination of overlapping applications, multiple versionsof the same application, redundant data storage and disparate computingpower. The result is duplicate applications and incompatible hardware.In some cases, businesses may not even have a complete understanding oftheir computing inventory.

Ideally, an organization's server farms would be a more homogeneousgroup of servers and applications with applications adequately balancedacross the servers in the most efficient and effective way. But moretypically, companies have an eclectic mix of computing products andhardware. The result is not only an inefficient computing system butalso a burdened staff that needs to be proficient on all of the varioushardware and software applications. To confront the issue, organizationsare consolidating their applications onto fewer, larger servers thathave increased availability and scalability.

Server consolidation can provide significant benefits, including areduction in the total cost of ownership, creation of a streamlined,manageable operation, increased system reliability, increased capacityutilization, and so on. Server consolidation can give an enterprise theability to scale processing and storage capacity without adding physicaldevices or subsystems, as well as the flexibility to partition andallocate resources as needed. Server consolidation can lead to astandardized computing environment, reducing the number of platforms,consolidating software products and system interfaces, and centralizingoperation and systems management procedures. The result is a reductionin staff training.

Server consolidation generally can be physical or logical consolidation.Physical consolidation extends a system's scalability and logicalconsolidation migrates multiple applications or databases into acentralized application or database. In addition, Physical consolidationcan thought of as two major sub-categories, server consolidation andstorage consolidation. Physical server consolidation takes a number ofservers and places their operating system instances into partitions ordomains of a larger server. Storage consolidation combines data fromdifferent sources into a single repository and format. Storage is one oftoday's most important asset-procurement considerations in the datacenter, with costs that can often rival or exceed server costs. Sincethe economic life of the storage exceeds that of most servers, today'sstorage decisions will affect operations for years to come.

For example, if a given server has excess capacity additionalapplications can be moved to that server resulting in a reduction of theoverall physical number of servers. Moreover, organizations typicallyconfigure systems to run at 50 to 60% utilization, leaving the extracapacity for peak workloads. If this unused capacity on various serversis consider for the number of servers in a large server farm, the amountof wasted resources can be enormous. By consolidating servers, theamount of unused capacity drops as dramatically as the number of serversno longer needed.

The subject patent document describes various methods and systems forautomating aspects of server consolidation.

SUMMARY OF THE INVENTION

The above-mentioned features are provided by a system and method fordeploying components such as computer programs on one or more ofcomputing devices such as servers in a server farm. A communicationdevice communicates over a network connection with one or more computingdevices. As a result, a data set is received over the network from eachcomputing device and the data set contains information indicative ofcharacteristics of the computing devices. Computer-executableinstructions capable of comparing characteristics of the at least onecomputing device to a set of predefined characteristic constraints areexecuted to determine whether the computing device meets predefinedinstallation rules. Installation will only proceed if thecharacteristics meet the predefined characteristic constraints.

The data set is received in a markup language such as XML. In that way,computer readable instructions for performing an XPATH query can be usedon the data set to retrieve a predetermined characteristic. Thecharacteristic constraints comprise minimum disk space on a drive,minimum memory, minimum number of processors, application not alreadyinstalled, a conflicting application is not installed, or whether arequired application is already installed.

BRIEF DESCRIPTION OF THE DRAWINGS

A consolidation system and method in accordance with the invention isfurther described below with reference to the accompanying drawings, inwhich:

FIG. 1 illustrates an exemplary diagram of a server farm consolidation;

FIG. 2 illustrates further detail of a consolidation system such aswould be used in the consolidation in FIG. 1;

FIG. 3 is an exemplary user interface for invoking the discovery aspectof the server consolidation;

FIG. 4 is a block diagram illustrating aspects of the discoverydeployment aspect of the system;

FIG. 5 is a high level flow diagram that illustrates the overall serverconsolidation;

FIG. 6 is an exemplary user interface showing a hierarchical folder viewof discovered server information;

FIG. 7 is an exemplary user interface for displaying details of anapplication discovered on a server;

FIG. 8 is an exemplary user interface the assists in the analysis ofdetermining commonality and differences among servers in a server farm;

FIG. 9 is an exemplary user interface that provides further analysisdetail on application commonality among servers;

FIG. 10 is an exemplary user interface for viewing servers by CPUutilization and memory constraints;

FIG. 11 is an exemplary user interface for selecting source and targetsystems for consolidation analysis;

FIG. 12 is an exemplary user interface that indicates results ofconsolidating a source server to a target server;

FIG. 13 is an exemplary user interface that displays the results of theprocess analysis;

FIG. 14 is an exemplary user interface for use in database consolidationand provide information on common SQL logins;

FIG. 15 is an exemplary user interface for use in a databaseconsolidation and provides information on table and columncompatibility;

FIG. 16A is an example of a system and application database model foruse in analysis of system and application compatibility;

FIG. 16B is an example of a database model for use in databasecompatibility and consolidation analysis;

FIG. 17 is an exemplary user interface for use in deploying applicationsto computer systems in a network such as in the deployment ofapplications in a server consolidation;

FIG. 18 is an exemplary user interface for selecting deployment rules inconnection with application deployment; and

FIG. 19 is an block diagram illustrating the deployment of applicationin a server consolidation application.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

A detailed description of illustrative embodiments of the presentinvention will now be described with reference to FIGS. 1-19. Althoughthis description provides detailed examples of possible implementationsof the present invention, it should be noted that these details areintended to be exemplary and in no way delimit the scope of theinvention.

14 FIG. 1 provides an overview of a primary aspect of the subjectinvention. In general, a consolidation service 115 is applied to a firstserver farm 110 to inventor the hardware, software, and data in thatserver farm. Aspects of that information are used to consolidate theserver farm 110 into a second server farm 120. The second server farm120 may represent a consolidation of the hardware, software, data, orsome combination of those items. The consolidation service 115 helps toautomate aspects of the consolidation through a process of discoveringwhat features are present in the first server farm 110, providing anorganized way of analyzing the discovered features to determineredundancies, utilization of resources, etc., and providing tools toassist in the deployment of the second, consolidated server farm.

A typical server farm, e.g., server farm 110 may have a variety ofservers 110 a through 110 f. The servers 110 a through 110 f in theexample server farm 110 may be of a variety of manufacturers,capabilities, power, etc. Moreover, as illustrated, the various serverscontain a mix of applications and data. For example, server 110 a runsapplications App A and App B, server 110 b runs application App A1 andmaintains database Data 1, server 110 c runs application App B1, server110 d runs application App C, server 110 e runs application App C1, andserver 110 f runs application App D and maintains database Data 2.Notably, the various applications may be various versions of the sameapplication. For example, application App A1 may be another instance ofapplication App A, whether the same or different version. Similarlyapplication App B1 may be another instance of application App B.Additionally, databases Data 1 and Data 2 may have a number of fields incommon such that the two databases could be merged into a singledatabase.

As noted above, consolidation service 115 provides tools to discover thevarious servers, hardware configuration, applications, databases, etc.contained with in server farm 110 for the primary purpose ofconsolidating the server farm into server farm 120.

Server farm 120 provides at least all of the functionality previouslyprovided by server farm 110, unless of course some of the functionalitywas intentionally removed during the consolidation. In the consolidatedserver farm 120, hardware may be combined, eliminated, upgraded etc.Similarly, applications may be consolidated to run on a single server,eliminated, or various version of a single application upgraded andcombined, e.g., applications App A and App A1 have been consolidatedinto application App A and applications App B and App B1 have beenconsolidated into application App B. Additionally, database Data 1 andData 2 have been consolidated into database Data 1+2.

FIG. 2 further illustrates aspects of the consolidation service runningon a consolidation management system 117. Consolidation system 117, runson one or more computing devices. The computing devices are coupled toserver farm 110 via network 210. Of course, showing the consolidationsystem 117 as separate from the server farm is for illustration purposesonly. Naturally, the service could run a server or system within theserver farm or without the server farm. Additionally, server farms 110and 120 are shown as separate server farms to illustrate thetransformation that the consolidation service facilitates. In manyinstances, the server farm 120 will be an update and consolidation ofserver farm 110 itself. That is, many of the servers in the server farmwill be reused and or redeployed in the consolidated server farm.

Discovery services 202 that run as part of the consolidation servicecomprise a variety of discovery services, e.g., Application/SystemDiscovery, SQL Server Discovery, and so on. The various discoveryservices are agents that are dispensed over network 210 to discover andinventory the various assets in the server farm, e.g., server farm 110.The discovered information on the various servers, e.g., 110 a-110 f,are then stored in consolidation database 206. After a sufficientportion of the assets on the server farm has been discovered, analysisservice 204 can then be used to analyze various aspects of the serverfarm. Finally, the analyzed information can be used to manage and deploya consolidated server farm, e.g., server farm 120.

Primarily, there are two types of inventory agents: System andApplication Agent and SQL Server Discovery Agent. There could be otheragent types as well. For example, an agent type could be designed togather information on Oracle databases, IBM databases, Object orienteddatabases, etc. Together these agents capture a number of data pointsrelative to system hardware, application and database configurations ina Microsoft Windows operating environment. The System and ApplicationAgent assists in the process of retrieving those data points necessaryfor analyzing existing applications to determine their suitability forconsolidation and to assist in the design of a consolidated applicationinfrastructure. System and Application Agent facilitates the capture ofa detailed inventory of the client's existing server estate, includingservers, applications, databases, devices, processors, memory and muchmore including the relationships of such information as defined in theSystem and Application Agent Inventory Model (described in furtherdetail in connection with FIG. 16A herein below). The SQL ServerDiscovery agent assists in the process of retrieving those data pointsnecessary for analyzing existing SQL Server database implementations todetermine their suitability for consolidation and to assist in thedesign of a consolidated SQL Server infrastructure. Although theoperation of the database discovery agent is described herein withreference to Microsoft SQL Server, the description and characteristicsof the agent also apply to Oracle database systems, suitably tailored tothe particular characteristics of Oracle systems.

SQL Server Database Agent facilitates the capture of a detailedinventory of the client's existing SQL Server estate including servers.SOL instances, databases, users and much more much more including therelationships of such information as defined in the SQL Server DatabaseInventory Model (described in further detail in connection with FIG. 16Bherein below).

FIG. 3 provides an illustrative invocation screen to set up and startthe discovery process. Window 302 provides various user interfacemechanisms to allow a user to control the discovery process. Folderportion 304 allows a user to select a storage location for the collecteddiscovery data, e.g., folder “/AAM/joe”. Target box 306 displays thename of the selected target server. Box 308 displays the list of filesin the selected folder. And tools portion 310 allows a user to selectthe discovery tool to use. In this example, the user has selected“Discover System.” The user could have selected an alternative discoverysuch as “Discover Database.”

Notably, the targets box 306 illustrates on technique for specifying atarget server by host name. Other techniques are also possible. Forexample, the system 117 could accept a comma separated list of serversor the system could query the domain controller and obtain a subnet listof IP addresses in the server farm. In general, the servers could beidentified by host name, host list, TCP/IP subnet, Microsoft ActiveDirectory site name, or domain name. Host name enables the user toselect a single server for inventory. In that instance, the userspecifies the name of the host machine, and a user name and passwordwith administrator privileges. Host list enables a user to select agroup of servers from a host list for inventory. TCP/IP subnet enables auser to select all servers within a specific TCP/IP subnet. In thatinstance, the user enters the network subnet address and a user name andpassword with administrator privileges for all systems in the subnet.Site name, enables a user to select all servers in a specific site. Inthis instance, a user enters the site name and a user name and passwordwith administrator privileges for all systems within the site. Domainname enables a user to select all servers in a domain. The user of thediscovery tool must enter the domain name and a user name and passwordwith administrator privileges for all systems within the domain. Afterdetermining the list of server addresses in the server farm, e.g.,server farm 110, the system logs-in to the target server, e.g., 110 a,and invokes the discovery process.

In general, the user will have to login to a target server as anadministrator to complete the discovery process. Hence, the discoveryservice will have to have access to an administrator account andpassword. This account and password will in general, but not necessarilybe the same on all of the servers throughout the server farm, e.g.,server farm 110. The discovery process looks up account name andpassword information for each system as it is processed. As a result,the login process can be automated to login to each of the plurality ofservers 110 a-110 f in server farm 110 using the username and passwordand thereafter invoking the discovery process. The discovery operationgenerally requires the organization to make available an existing userID and password or create a new user ID and password for the serversthat are targeted for discovery. The user ID should have administratorprivileges, including the rights to debug programs and to load andunload device drivers, and can be removed from the systems as soon asthe discovery task is completed

The Discovery tool launches a remote agent into each designated servers,e.g., 110 a, to capture information about all of the applications andprocesses running in that system. The agent writes the capturedinformation back to the consolidation computer system 117 as an XMLfile, where it is stored in consolidation database 206. The remote agentis then removed from the target server, e.g., 110 a, leaving no trace ofitself.

The discovery process generally employs remote procedure calls (RPC),interprocess communication (IPC), and named pipes to tightly couple theparent process running on one computing device (i.e. the computingdevice hosting the consolidation system 117) with the server computer,e.g., 110 a, that is being discovered. RPC enables applications to callfunctions remotely. Therefore, RPC makes IPC as easy as calling afunction. RPC operates between processes on a single computer or ondifferent computers on a network.

Named pipes are used to transfer data between processes that are notrelated processes and between processes on different computers.Typically, a named-pipe server process creates a named pipe with awell-known name or a name that is to be communicated to its clients. Anamed-pipe client process that knows the name of the pipe can open itsother end, subject to access restrictions specified by named-pipe serverprocess. After both the server and client have connected to the pipe,they can exchange data by performing read and write operations on thepipe.

Discovery is the process of harvesting system information andinformation about running processes on specified servers located in aserver farm, and storing the information in database 206 of FIG. 2. Asthe discovery operation finishes on each target server, the agent isremoved from the server and the link to the server from the externalsystem is terminated. In summary, no trace of the discovery operationshould remain in the organization's system.

Multiple discoveries can be done by scheduling discovery at specifictime intervals to capture those applications or processes that run onlyat a particular time or the discovery operation can be run againmanually. Each time the discovery operation is repeated, a new revisionof the server XML file is created. All revisions are stored andavailable in the version history.

The type of information discovered by Application and Process Discoveryincludes hardware information, such as the number of processors on agiven system, available processors on a given system, processor leveland revision, devices, disk drive characteristics and capacities, as soon. System information discovered includes system name, page size,operating system version, operating system build, network connectivity,and so on. Process and dependency information discovered includes activeprocesses and their associated dependencies (both component andconfiguration), processor usage at both the system and the processlevel, memory usage at both the system and the process level, processcreation time, process ID, process owner, process handles, process anddependency versions and timestamps, process and dependency descriptions.

SQL Server Database discovery is designed to facilitate SQL serverConsolidation. It automates much of the information gathering andanalysis process. It complements the information gathered throughProcess discovery. The information gathered is a detailed inventory ofthe customer's existing SQL Server estate—Servers, Instances, Databases,User and so on. The information collected is stored in database 206 andis used by consolidation system 117 during the analysis process.

FIG. 4 further illustrates aspects of the discovery process. The targetserver, e.g., 110 a, is preferably selected through a GUI interface aspart of the overall discovery process. A selected discovery agent 406 ispushed on the target server with a privileged user account and startscollecting information into an XML file format on client machine. TheXML file is stored in consolidation database 206 with a trackingversion. As part of the load process, the information in the XML file isread and transformed into a series of relational records and stored in acache database for query purposes.

The consolidation database 206 is used to store the informationcollected from target SQL servers. The database type is preferably arelational database. In addition and not to be confused withconsolidation database 206, there are target databases, e.g., target SQLserver databases: Such databases are the instances where the inventoryis taken from. To access these databases, the database discovery processrequires SQL admin privileges account on the target SQL server.

To connect to an instance of SQL Server, typically two or three piecesof information are required, including the network name of the computeron which the SQL Server instance is running, and the instance name (thisis necessary in the case where only a particular instance is to bediscovered).

Initially, after login, consolidation system 117 copies a procedure overto the target server, e.g., 110 a. In particular, it copies a remoteservice executable program 404 to admin$ share on the server computer.Thereafter, four named pipes 402 are started up as shown in FIG. 4between the remote service 404 and consolidation system 117. The fournamed pipes 402, stdin, stdout, stderr, and control are used tofacilitate communication between the consolidation system 117 and theserver 110 a. The remote service 404 establishes the connection betweenconsolidation system 117 and server 110 a using the named pipes 402.After the named pipes 402 have been established, a discovery procedure406, e.g., the discovery procedure selected from the tools box 310 inFIG. 3, is copied to sever 110 a.

When the discovery process 406 is in place on target server 110 a, thecontrol pipe is used to run discovery procedure 406. The named pipes402, i.e. stdin, stdout, stderr, and control are routed to the discoveryprocedure. The discovery process 406 then performs the appropriateinventory collection, as described more fully below, and sends back anXML file that includes the data describing the assets on target server110 a. Thereafter, the discovery process 406 terminates and then ispreferably shut down and also removed from target server 110 a. Theprocess is then repeated for the remaining servers in the server farm110, e.g., 110 b, 110 c, and so on.

When the Application and System discovery agent starts on the targetserver 110 a, the processes and DLLs information is collected usingvarious system calls. To obtain a list of all processes in a Windows2000 Server operating system environment, the following calls are used:ULONG (_(——)stdcall *NtQuerySystemInformation)(  ULONGSystemInformationClass,  PVOID SystemInformation,  ULONGSystemInformationLength,  PULONG ReturnLength  );

NtQuerySystemInformation is an internal Windows function that retrievesvarious kinds of system information.

SystemInformationClass indicates the kind of system information to beretrieved. The information includes: the number of processors in thesystem, information about the resource usage of each process, includingthe number of handles used by the process, the peak page-file usage, andthe number of memory pages that the process has allocated.

SystemInformation points to a buffer where the requested information isto be returned. The size and structure of this information variesdepending on the value of the SystemnInformationClass parameter:

SystemInformationLength is the size of the buffer pointed to by theSystemInformation parameter, in bytes.

ReturnLength is an optional pointer to a location where the functionwrites the actual size of the information requested.

Another call is used that provides a starting address to obtain theinformation about what DLLs are loaded by a process. That call is asfollows: ULONG (_(——)stdcall *NtQueryInformationProcess)(  PVOIDProcessHandle,  INT ProcessInformationClass,  PVOID ProcessInformation, ULONG ProcessInformationLength,  PULONG ReturnLength );

ProcessHandle specifies the handle to the process for which informationis to be retrieved.

ProcessInformationClass specifies the type of process information to beretrieved. This parameter can either retrieves a pointer to a PEBstructure that can be used to determine whether the specified process isbeing debugged, and a unique value used by the system to identify thespecified process or whether the process is running in the WOW64environment (WOW64 is the x86 emulator that allows Win32-basedapplications to run on 64-bit Windows).

ProcessInformation is a Pointer to a buffer supplied by the callingapplication into which the function writes the requested information.

ProcessInformationLength is the size of the buffer pointed to by theProcessInformation parameter, in bytes.

ReturnLength is a pointer to a variable in which the function returnsthe size of the requested information.

The information so collected is then put into an XML file andtransmitted back to consolidation computer system 117. The below XMLprovides an example of a portion of such an XML file.  <?xmlversion=“1.0” encoding=“ISO-8859-1” ?> <Discovery type=“Process”><PE_SysInfo ID=“5008DJUL1030-SI” discoverVersion=“2.0.0”captureTimeGMT=“21:10:30 30 Oct 2003” captureTimeNumeric=“1067548230”systemName=“USMV-MUTSCHGO” systemMake=“Dell Computer Corporation”systemModel=“Dell WORKSTATION PWS360” osMajorVersion=“5”osMinorVersion=“1” osBuild=“2600” osRev=“Service Pack 1” pageSize=“4096”allocationGranularity=“65536” totalMemory=“1072689152”availableMemory=“634216448” totalVirtualMemory=“2147352576”availableVirtualMemory=“2111578112” totalPageFile=“2581708800”availablePageFile=“2110324736” memoryLoad=“40” cpuLoad=“1.7”systemDirectory=“C:\WINDOWS\System32\”>  <PE_SysInfoEx ID=“EI”parent_ID=“5008DJUL1030-SI” servicePackMajor=“1” servicePackMinor=“0”productType=“PROD_WORKSTATION” InstalledPkg=“PKG_SINGLEUSERTS” /><PE_HdweInfo ID=“HI” parent_ID=“5008DJUL1030-SI” numberOfProcessors=“2”availableProcessorMask=“3” processorLevel=“15” processorRevision=“521”> <PE_ProcessorSpeed parent_ID=“HI” procNum=“0” speed=“2992” /> <PE_ProcessorSpeed parent_ID=“HI” procNum=“1” speed=“2992” /><PE_Device parent_ID=“HI” deviceLocation=“LPT1” cmpLocation=“”> <deviceName>Printer Port Logical Interface</deviceName>  </PE_Device><PE_Device parent_ID=“HI” deviceLocation=“USB Device” cmpLocation=“”> <deviceName>ViewSonic Color Pocket PC V37</deviceName>  </PE_Device><PE_Device parent_ID=“HI” deviceLocation=“” cmpLocation=“0,0,0,1”> <deviceName>HL-DT-ST RW/DVD GCC-4480B</deviceName>  </PE_Device> ...<PE_AppCatalogItem parent_ID=“5008DJUL1030-SI” appName=“PowerDVD”appVersion=“” publisher=“” msiGuid=“{6811CAA0-BF12-11D4-9EA1-0050BAE317E1}”>  <installLocation />  <installSource /> </PE_AppCatalogItem> <PE_AppCatalogItem parent_ID=“5008DJUL1030-SI”appName=“Easy CD Creator 5 Basic” appVersion=“5.3.4.21” publisher=“RoxioInc” msiGuid=“{609F7AC8-C510- 11D4-A788-009027ABA5D0}”> <installLocation />  <installSource />  </PE_AppCatalogItem><PE_AppCatalogItem parent_ID=“5008DJUL1030-SI” appName=“Microsoft Office2000 SR-1 Premium” appVersion=“9.00.9327” publisher=“MicrosoftCorporation” msiGuid=“{00000409-78E1-11D2-B60F-006097C998E7}”> <installLocation /> <installSource>\\usmv-sms\UITSoftware\STD2000.S2A\</installSource> </PE_AppCatalogItem> <PE_AppCatalogItem parent_ID=“5008DJUL1030-SI”appName=“Microsoft SQL Server 2000” appVersion=“8.00.761”publisher=“Microsoft” msiGuid=“”>  <installLocation>C:\ProgramFiles\Microsoft SQL Server\MSSQL</installLocation>  <installSource /> </PE_AppCatalogItem> ... <PE_Process ID=“Proc.1588”parentSystem_ID=“5008DJUL1030-SI” processName=“AGENTSRV.EXE”processId=“1588” depth=“5” affinityMask=“3” processOwner=“NTAUTHORITY\SYSTEM” parentProcess_ID=“Proc.772” startTime=“09:21:25 29 Oct2003” startTimeNumeric=“1067448085” handleCount=“119” basePriority=“8”cpuTime=“1441406250” percentCpuTime=“0.1” hasServices=“true”ownProcess=“false” peakVirtualSize=“187858944” pageFaultCount=“127666”peakWorkingSetSize=“107339776” workingSetSize=“184320”quotaPeakPagedPoolUsage=“51872” quotaPagedPoolUsage=“50056”quotaPeakNonPagedPoolUsage=20446” quotaNonPagedPoolUsage=“4400”pagefileUsage=“18952192” peakPagefileUsage=“107180032”privatePageCount=“18952192” version=“7.0.3.0892” usedModules=“Mod.0Mod.1 Mod.2 Mod.3 Mod.4 Mod.5 Mod.6 Mod.7 Mod.8 Mod.9 Mod.10 Mod.11Mod.12 Mod.13 Mod.14 Mod.15 Mod.16 Mod.17 Mod.18 Mod.19 Mod.20 Mod.21Mod.22 Mod.23 Mod.24 Mod.25 Mod.26 Mod.27 Mod.28 Mod.29 Mod.30”> <description>Agent Service Module</description>  <fullPath>C:\LegatoConnected\AGENTSRV.EXE</fullPath>  <commandLine>“c:\LegatoConnected\AgentSrv.EXE” -asv</commandLine>  </PE_Process> <PE_ProcessID=“Proc.772” parentSystem_ID=“5008DJUL1030-SI”processName=“SERVICES.EXE” processId=“772” depth=“4” affinityMask=“3”processOwner=“NT AUTHORITY\SYSTEM” parentProcess_ID=“Proc.728”startTime=“09:21:21 29 Oct 2003” startTimeNumeric=“1067448081”handleCount=“365” basePriority=“9” cpuTime=“79843750”percentCpuTime=“0.0” hasServices=“true” ownProcess=“false”peakVirtualSize=“54595584” pageFaultCount=“4985”peakWorkingSetSize=“7499776” workingSetSize=“4673536”quotaPeakPagedPoolUsage=“58560” quotaPagedPoolUsage=“35612”quotaPeakNonPagedPoolUsage=“14264” quotaNonPagedPoolUsage=“11040”pagefileUsage=“3964928” peakPagefileUsage=“4517888”privatePageCount=“3964928” version=“5.1.2600.0 (xpclient.010817-1148)”usedModules=“Mod.217 Mod.1 Mod.2 Mod.9 Mod.5 Mod.6 Mod.3 Mod.4 Mod.66Mod.218 Mod.212 Mod.219 Mod.84 Mod.220 Mod.73 Mod.221 Mod.17 Mod.18Mod.50 Mod.37 Mod.89 Mod.65 Mod.19 Mod.222 Mod.30 Mod.223 Mod.7 Mod.42”> <description>Services and Controller app</description> <fullPath>C:\WINDOWS\SYSTEM32\SERVICES.EXE</fullPath> <commandLine>C:\WINDOWS\system32\services.exe</commandLine> </PE_Process> ... <PE_Module version=“1.02.0814.0000” ID=“Mod.392”parent_ID=“5008DJUL1030- SI” base=“1505034240” size=“36864”memoryMapped=“false” creationTime=“8/29/2002 2:00 AM”> <moduleDescription>WinInet Soap Connector Library</moduleDescription> <path>C:\Program Files\Common Files\MSSoap\Binaries\WISC10.DLL</path> <imageName>WISC10.DLL</ImageName>  </PE_Module> ...  </PE_SysInfo> </Discovery>

When the SQL Server discovery agent starts on the target server 110 a,the following actions are performed:

1. The agent captures the SQL Server name and version on the targetmachine 110 a.

2. For each instance of the SQL Server on target machine 110 a, thefollowing information is captured:

-   -   The database schema's present is determined, and for each        database schema information is collected such as tables, views,        indexes, roles, etc.    -   User logins, permissions and roles    -   User objects in the master db    -   Database names and logins and database client names    -   SQL configuration settings    -   Collation settings    -   Jobs and tasks    -   SQL alerts    -   Replication    -   DTS packages list    -   Database size and log size information

In general, the captured data is used to detect differences betweendatabase objects for duplicate databases on multiple servers. Thefollowing database objects are captured for comparison:

Roles, Users, Aliases, Defaults, Rules, Functions, User defined datatypes, User messages, Tables, Views, Indexes, Extended procedures,Stored procedures and Triggers. There are several methods available tocapture this information. The preferred method uses T-SQL and collectsthe catalogue information from system tables. The below descriptionillustrates an implementation for SQL Server available from MicrosoftCorporation. Nevertheless, the overall technique is also applicable toother database systems such as Oracle database systems.

SQL Server available system stored procedures are used to captureinformation. For example, a join query against Sysprocesses andsysdatabases tables captures some of the information as follows: SELECTdbs.[name], [program_name],[loginame] FROM [master].[dbo].[sysprocesses]procs, [master].[dbo].[sysdatabases] dbs Where procs.[dbid] = dbs.[dbid]And Len([program_name]) > 0

The function interrogates Master db for any user objects. System Storedprocedures are used to capture the data. The function looks for usertype objects in the master database and the ones found along with theirdescription and contents is written to XML file to be stored in thecache database.  SELECT  CONVERT(char(32), hostname( )) as MachineName,ServerName = CASE @@servername WHEN null THEN CONVERT(char(32),host_name( )) ELSE CONVERT(char(32), @@servername) END, o.name asStoredProcName, u.name as OwnerName FROM master..sysobjects o,master..sysusers u WHERE   o.uid = u.uid and o.type = ‘P ’and o.category= 0 and o.name <> ‘sp_helpsql’

To identify the potential login problems like duplicate names in morethan one server and the conflicting permission, this function capturesthe logins and permissions via the stored procedures available.

For each instance get the list of logins and their roles for eachdatabase within that instance.

The configuration information such as from sp_configure, is extractedand compared against the default settings for a particular version ofSQL Server.

SQL Server function ServerProperty is used to collect product version,edition, service pack, collation, etc. as illustrated below: SelectCONVERT(char(32), serverproperty(‘collation’) )as ‘Collation’,CONVERT(char(32), serverproperty(‘Edition’))as ‘Edition’,CONVERT(char(32), serverproperty(‘Engine Edition’) )as ‘Engine Edition’,CONVERT(char(32), serverproperty(‘InstanceName’) )as ‘InstanceName’,CONVERT(char(32), serverproperty(‘IsClustered’))as ‘IsClustered’,CONVERT(char(32), serverproperty(‘IsFullTextInstalled’))as‘IsFullTextInstalled’, CONVERT(char(32),serverproperty(‘IsIntegratedSecurityOnly’))as‘IsIntegratedSecurityOnly’, CONVERT(char(32),serverproperty(‘IsSingleUser’))as ‘IsSingleUser’, CONVERT(char(32),serverproperty(‘IsSyncWithBackup’))as ‘IsSyncWithBackup’,CONVERT(char(32), serverproperty(‘LicenseType’))as ‘LicenseType’,CONVERT(char(32), serverproperty(‘MachineName’))as ‘MachineName’,CONVERT(char(32), serverproperty(‘NumLicenses’))as ‘NumLicenses’,CONVERT(char(32), serverproperty(‘ProcessID’))as ‘ProcessID’,CONVERT(char(32), serverproperty(‘ProductVersion’))as ‘ProductVersion’,CONVERT(char(32), serverproperty(‘ProductLevel’))as ‘ProductLevel’,CONVERT(char(32), serverproperty(‘ServerName’))as ‘ServerName’ Fornon-2000 SQL Server some of these fields will be null.

The below functions captures lists of Jobs, via sysjobs table of msdb,Alerts via sysAlerts table and Operators via sysOperators for anInstance. Jobs: Select CONVERT(char(32), host_name( )) as MachineName,ServerName = CASE @@servername WHEN null THEN CONVERT(char(32),host_name( )) ELSE CONVERT(char(32), @@servername) END,* frommsdb..sysjobs Alerts: SELECT CONVERT(char(32), host_name( )) asMachineName, ServerName = CASE @@servername WHEN null THENCONVERT(char(32), host_name( )) ELSE CONVERT(char(32), @@servername)END,[id],[Name],Event_source, Event_category_id, Event_id, Message_id,Severity, Enabled,Delay_between_responses, Last_occurrence_date,Last_occurrence_time, Last_response_date, Last_response_time,Notification_message, Include_event_description, Database_name,Event_description_keyword, Occurrence_count, Count_reset_date,Count_reset_time, Job_id, Has_notification, Flags,Performance_condition, Category_id, “ as Event_category_name, ” asDelay_between_notifications, “ as Task_id, ” as Has_email_notification,” as Has_pager_notification FROM msdb..sysalerts Operators: DECLARE@SQLVersion varchar(4) SELECT @SQLVersion = SUBSTRING(@@version, 23, 4)--Extract the information, dependant on SQL version IF (@SQLVersion =‘6.50’)  SELECT CONVERT(char(32), host_name( )) as MachineName,ServerName = CASE @@servername WHEN null THEN CONVERT(char(32),host_name( )) ELSE CONVERT(char(32), @@servername) END,*, “ asNetsend_address, ” as Last_netsend_date, “ as Last_netsend_time, ” asCategory_id FROM msdb..sysoperators ELSE  IF (@SQLVersion = ‘7.00’) or(@SQLVersion = ‘2000’)   SELECT CONVERT(char(32), host_name( )) asMachineName, ServerName = CASE @@servername WHEN null THENCONVERT(char(32), host_name( )) ELSE CONVERT(char(32), @@servername)END,* FROM msdb..sysoperators

Where replication is allowed, information is collected on databases andreported in a list, server, instance and dbnames along with replicationrole (Publisher, Distributor, Subscriber) and replication type. Thesystem Store procedure ‘sp_helpreplicationdboption’ is utilized tocapture replication information. To capture DTS packages info, thefollowing SQL statements are exercised: DECLARE @SQLVersion varchar(4)DECLARE @SQLString varchar(255) SELECT @sqlversion =SUBSTRING(@@version, 23, 4) IF (@SQLVersion = ‘6.50’)  select ‘’ ELSE IF (@SQLVersion = ‘7.00’)   IF @@ServerName is not Null    SELECT@SQLString = ‘SELECT CONVERT(char(32), host_name( )) as MachineName,CONVERT(char(32), @@servername) asServerName,name,id,versionid,cast(description AS char(25)) asShortDescription, categoryid,createdate,owner, owner_sid, “” asPackageType from msdb..sysdtspackages’   ELSE    SELECT @SQLString =‘SELECT CONVERT(char(32), host_name( )) as MachineName,CONVERT(char(32), host_name( )) asServerName,name,id,versionid,cast(description AS char(25)) asShortDescription, categoryid,createdate,owner, owner_sid, “” asPackageType from msdb..sysdtspackages’  ELSE   IF @SQLVersion = ‘2000’   IF @@ServerName is not Null     SELECT @SQLString = ‘SELECTCONVERT(char(32), host_name( )) as MachineName, CONVERT(char(32),@@servername) as ServerName,name,id,versionid,cast(description ASchar(25)) as ShortDescription, categoryid,createdate,owner,owner_sid,packagetype from msdb..sysdtspackages’    ElSE     SELECT@SQLString = ‘SELECT CONVERT(char(32), host_name( )) as MachineName,CONVERT(char(32), host_name( )) asServerName,name,id,versionid,cast(description AS char(25)) asShortDescription, categoryid,createdate,owner, owner_sid,packagetypefrom msdb..sysdtspackages’ EXEC(@SQLString)

In order to get the database size and log size for each database dbsize(used and free), and logsize (used and free) are used and reported withserver/instance/dbname. The below is sample code to go to each databaseand execute stored procedure ‘sp_spaceused’ to capture some of theinformation. DECLARE AllDatabases CURSOR FOR SELECT name FROMsysdatabases --WHERE dbid > 4 OPEN AllDatabases DECLARE @DBNameVarVARCHAR(128) DECLARE @Statement VARCHAR(255) FETCH NEXT FROMAllDatabases INTO @DBNameVar WHILE (@@FETCH_STATUS = 0) BEGIN  SELECT@Statement = ‘USE ’ + @DBNameVar + CHAR(13)   + ‘ exec sp_spaceused’ EXEC (@Statement)  FETCH NEXT FROM AllDatabases INTO @DBNameVar ENDCLOSE AllData bases DEALLOCATE AllDatabases

To capture log size information, the following SQL statement is used:DBCC SQLPERF(LOGSPACE) WITH NO_INFOMSGS

The database information captured is formatted into an XML file andtransmitted back to the consolidation system 117. An example portion ofsuch and XML file is as follows: <?xml version=“1.0”encoding=“ISO-8859-1” ?> <Discovery type=“Database”> <DD_ServermachineName=“USMV-VAZEHGMM1” windowsVersion=“5.1.2600 Service Pack 1Build 2600” discoverVersion=“2.0.0” processorCount=“1”processorActiveMask=“” OS_Name=“Windows_NT 5” systemName=“USMV-VAZEHGMM1” systemManufacturer=“Dell Computer Corporation”systemModel=“Dell OPTIPLEX GX260” systemType=“x86” processor=“x86 Family15 Model 2 Stepping 4 GenuineIntel ˜ 2000 MHz” BIOSVersion=“DELL - 6”locale=“United States” timeZone=“Pacific Standard Time”windowsDirectory=“C:\WINDOWS” bootDevice=“\Device\HarddiskVolume3”systemDirectory=“C:\WINDOWS\System32” physicalMemory=“1046524.00”availablePhysicalMemory=“102700.00” virtualMemory=“2097024.00”availableVirtualMemory=“2040440.00” pagefileSpace=“0.00”>  ...<DD_Database serverName=“USMV-VAZEHGMM1\DESKTOPSERVER” dbName=“Analysis”owner=“sa” created=“Sep 3 2003” status=“Status=ONLINE,Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=SIMPLE,Version=539, Collation=SQL_Latin1_General_CP1_CI_AS, SQLSortOrder=52,IsAutoClose, IsAutoShrink, IsTornPageDetectionEnabled,IsAutoCreateStatistics, IsAutoUpdateStatistics” compatibility_level=“80”logSize=“0.00” logspaceUsed=“0.00” IStatus=“” dbSize=“24.06”unalloc_s=“1.91” reserv_s=“21664.00” data_s=“15552.00” index_s=“5736.00”unused_sp=“376.00” transPublish=“0” mergePublish=“0” dbOwner=“True”readOnly=“False”> <DD_SchemaInfo> <DD_TableserverName=“USMV-VAZEHGMM1\DESKTOPSERVER” dbName=“Analysis”tableName=“DD_Alert“>  <DD_ColumnserverName=“USMV-VAZEHGMM1\DESKTOPSERVER” dbName=“Analysis”tableName=“DD_Alert” columnName=“fileVersion” colid=“1”coltype=“nvarchar” collen=“510” colprec=“255” colscale=“0”isnullable=“0” collation=“SQL_Latin1_General_CP1_CI_AS” />  </DD_Table> <DD_User serverName=“USMV-VAZEHGMM1\DESKTOPSERVER” dbName=“Analysis”loginName=“” groupName=“” userName=“guest” />  </DD_SchemaInfo> </DD_Database>  </DD_Instance>  </DD_Server>  </Discovery>

Here is a more detailed XML layout for the Schema information part only.

For each database within an SQL instance, there is an element called<SchemaInfo> containing the information. <SchemaInfo   <TableInfo  <ColumnInfo name = “columnName goes here”       Description = “columndescription goes here” />   <ColumnInfo name = “columnName goes here”      Description = “column description goes here” />   <ColumnInfo name= “columnName goes here”       Description = “column description goeshere” />    .......    ....... more columns   <TriggerInfo name =“triggerName “ Description = “ trigger   description” />    .......   .......additional triggers   <ConstraintInfo name = “constraintName “       Description = “constraint description” />    .......   .......additional constraints   <IndexInfo name = “indexName “Description = “index   description” />    .......    .......additionalindexes  </TableInfo>  ..........  ..........additional tables go here <ViewInfo name = “viewName goes here”       Description = “viewdescription goes here” </ViewInfo>  .......  ........ more views <UdtInfo name = “UDTName goes here”      Description = “UDT description“ </UdtInfo>   .......   ........ more user-defined types  <FunctionInfoname = “functionName goes here”       Description = “functiondescription goes       here” </FunctionInfo>  ........  ......... moreuser-defined functions  <SPInfo name = “stored-procedureName goes here”    Description = “Stored-procedure description goes     here” </SPInfo>  ........  ......... more user stored-defined procs  <DefaultsInfo name= “defaultName goes here”      Description = “default description goeshere” </DefaultInfo>   ........  ......... more defaults in here <RuleInfo name = “ruleName goes here”      Description = “ruledescription goes here” </RuleInfo>   ........   ......... more rules inhere  <UserInfo name = “userName goes here”       Description = “userdescription goes here” </UserInfo>   ........   ......... more user infoin here  <UserMsgInfo name = “userMsgName goes here”      Description =“userMsg description goes      here” </UserMsgInfo>   ........  ......... more user messages info in here </SchemaInfo>

After the information for a particular server has been discovered, theprocess is repeated for another server, e.g., 110 b, until all of theservers of interest in a server farm, e.g., 110, have been discovered.After a sufficient number of the servers has been discovered, and morelikely after a substantial number of the servers have been discovered,the analysis tools can be used to assist in aspects of the consolidationprocess.

Analysis tools interpret and generate reports from the informationobtained during the discovery process. Any of the discovery files can beopened, including revisions of each file. Thus, the analysis process canbe tailored to focus on any subset of discovered server assets. Once theset of discovery files are opened, the analysis tools summarizes thenumber of systems and processes being analyzed.

Although the analysis is described herein below in the context of serverconsolidation wherein the applications, databases, etc. are move to oneor more other target servers, the analysis aspects and indeed many ofthe tools described herein also apply to a single server. That is,aspects of a server can be compared to itself at different points intime. Hence, it is important to note that the discovered XML filesdescribed above are maintained by server by time. This allows two formsof time-based analysis. In one case, the processes in use and systemloading for a server can be examined as they change over time. In theother case, a server can be compared to itself after consolidationactivities have occurred. That will allow a consolidation to be rolledback. For instance if an application and its dependencies were movedfrom a source server to a consolidation target server and theapplication and some or all of its dependencies were subsequentlyremoved from the source server, the analysis tools described herein willallow all of the features to be applied in comparing one version of aserver's inventory to a different version of the same server'sinventory. In that way, a user can revert back to an early system state.Similarly, the system could be used to track what inventory was added toa particular server and at what version the additions were made. In thisway, the analysis tool may allow a user to quickly identify whichapplications were added to a server that may have caused it to exceedutilization criteria. The important point is that the tools describedherein apply to other contexts than the context of comparing a sourceserver to a target server for the purpose of consolidation.

Reports that highlight opportunities for application consolidation andapplication coexistence can be generated. For example, the CommonProcesses report lists the processes running on two or more systemswithin the server farm. Applications associated with common processesare consolidation candidates. The analysis tools provide custom reportoutput, sorted in any manner, on any stored attribute.

Reports can be generated based on queries of any of the following dataelements:

* Hardware Information

Number of processors on a given system

Available processors on a given system

Processor level and revision

Devices on a PCI bus

Non-network disk drives on a system and characteristics of the drives

System Information

System name

Operating system version

Operating system build

Total and available memory

Applications

Application name

Application version

Processes

Process name and process ID

Process owner

Process dependencies

Process and dependency descriptions

Process and dependency versions and timestamps

Actual memory and virtual memory

Memory paging

Processor usage

Actual CPU time

Number of handles open on a process

FIG. 5 provides a flow chart of the general process involved inanalyzing the collected data for the purpose of consolidation. Thefigure uses the example of application consolidation. Nevertheless, avery similar process will happen for data consolidation. Obviously, ifall of the applications and data on a given server are consolidated toother servers, that server is a candidate for removal from the serverfar altogether, resulting in a physical consolidation.

Initially, a determination is made whether data has been discovered fora server or servers of interest (step 502). An initial high levelanalysis is made to determine potential consolidation candidate servers(step 504, 506). This process is described more fully below inconnection with the analysis user interface figures. At step 508, adetermination is made regarding the potential benefit of aconsolidation. If there is a potential benefit, then all of thenecessary data for consolidation is collected (step 510). This mayalready have happened, if so that step can be skipped. However, all ofthe detailed information necessary for consolidation should be availablesuch as an application and all of its dependent modules, or a databaseand all of its tables and columns (step 512). Thereafter, an analysis isperformed to determine the common components on the candidate servers,e.g., the number of applications and modules that are common between thecandidate servers. Next a list of potential consolidation groupings aremade, e.g., the e-mail applications can be grouped together on onemachine (steps 514, 516). After the candidate applications and/ordatabases are identified, the dependencies are compared for variations,e.g., is the DLL on one candidate server the same version as a DLL onthe other server (steps 518, 520). After the applications and/ordatabases have been consolidated, performance values of the consolidatedserver are measured to ensure that it has the capacity to perform theadded tasks (steps 522, 525). Thereafter, the entire process can berepeated and new information discovered for the consolidated server farmto determine whether further consolidation is beneficial.

FIG. 6 provides an illustration of an exemplary user interface (UI) foruse in consolidation analysis. Window 600 provides an interface forusers to browse through the various files of discovery informationcollected from the servers in the server farm of interest, e.g., 110. Tothat end Window 600 has a pane 602 with a hierarchically arrangedcatalog of server information arranged into folders. By selecting one ofthe folders, displayed in pane 602, the user is presented in pane 604with a catalog of the XML files (described above) that have beencollected from the various servers. Notably, each of the XML filescontains a time stamp 606 and version number 608. That allowsinformation to be discovered on the same server at different times andto monitor server changes.

FIG. 7 depicts an example of a portion of the UI that assists in theanalysis of server consolidation by allowing a user to view all of theinventory of discovered servers. Window 700 is divided into two panes702 and 703. Pane 702 provides a hierarchical view of the discoveredinformation for a server. Here for example, a user has opened ahierarchical view of the system inventory for server OTG-SYS-3 and hasselected Applications and Adobe Acrobat 5.0 (704) in particular. Theattributes 706 and corresponding values 708 for that application aredisplayed in pane 703.

FIG. 8 depicts an example of a portion of the UI that assists in theanalysis of server consolidation by presenting a graphic of thecommonality of applications on selected servers. Window 800 provides aview of three pie charts 802, 804, and 806. Pie chart 802 graphicallydepicts the applications that appear on more than one server with thoseapplications that have different and the same versions appearing indifferent colors or shading. Here for example, pie chart 802 shows thatthere is a very high commonality of applications on selected servers,suggesting that benefits may be gained through consolidation. Similarly,pie chart 806 indicates the amount of commonality of process and shows ahigh commonality in this example. Pie chart 804 provides a graphicdepiction of the commonality of process dependencies in the servers ofinterest. The details of the commonality can be viewed in more detail asshown in FIG. 9.

FIG. 9 provides an example portion of the UI that provides furtherdetails on process commonality. Window 900 is divided into two panes 902and 904. Pane 902 provides a listing of the servers in the server farmto undergo consolidation analysis, e.g., server farm 110. Pane 904provides a list of processes by process name 906. Pane 904 also showswhich server the process 908 is on, along with the discovery informationrevision 910. From this window 900, a user can further analyze candidateservers for consolidation by determining which servers are running keyprocesses in common.

Additional analysis functions provide an indication of memory andprocessor loads and assist in identifying servers that are underloadedor overloaded. Servers that are underloaded may be candidates to havetheir applications consolidated on to another server. Additionally,servers that are already overloaded are not good candidates to acceptadditional applications in a consolidation and may, in fact, benefitfrom have one or more of its applications moved to another server. FIG.10 provides an example UI to display CPU and memory utilization. Window1000 has two panes 1002 and 1004. Pane 1002 provides a hierarchicallisting of server inventory. Pane 1004 provides a display showing thecombined average CPU and memory utilization for servers in the systemand help with compatibility analysis. Bar 1006 provides a graphicindication of the CPU and memory load on a particular server and has aportion 1006 a that indicates CPU load and a portion 1006 b thatindicates memory load. Slides 1008 and 1010 provide a mechanism by whicha user can filter the results, i.e., by setting the slide 1008 a usercan exclude those systems from the display whose minimum CPU utilizationis less than the threshold set by the slider and by setting the slide1010 a user can exclude those systems whose CPU utilization exceed themaximum CPU utilization threshold set by the slider. Similarly, slides1012 and 1014 allow a user to filter on memory utilization by settingthe minimum and maximum thresholds. The filter allows a user to quicklyidentify source servers that are candidates for consolidation. The Minuptime hours spin box 1016 can be changed to exclude those systems fromthe display whose time of operation since the last restart is less thanthe number of hours indicated.

FIG. 11 provides further details on the analysis tools provided forserver consolidation. Here Window 1110 provides two panes 1102 and 1104.Pane 1102 lists all of the servers in the server farm, e.g., 110 thathave been discovered by the System and Application discovery tool. Pane1104 provides a mechanism for a user to select process or systemcompatibility by way of radio buttons 1104 and 1106. In this example,the user has selected system compatibility analysis. Thereafter, a usecan select a source system 1108, e.g., a server candidate forconsolidation and one or more target systems 1110. Source systemprocesses are display in box 1112.

FIG. 12 further details the analysis by display indicators of the resultof consolidating the source server to the target server. Window 1200provides the results of the selections made in Window 1100 as shown inFIG. 11. Window 1200 displays the results of consolidating selectedsource server OTG-TEST-SRV3 [1.2] on to target server OTG-TEST-SRV2[1.2]. The target system is displayed in column 1202. Column 1204indicates how many DLLs are the same on the source and target serversand column 1206 indicates how many common DLLs are different. A commonDLL is one that is used by all applications in the system, e.g., bybeing located in the Windows System32 directory. Column 1208 indicatesthe target load percentage prior to consolidation and column 1210indicates the target load percentage after consolidation. CPUutilization values from the source server are normalized to theprocessing power of the target server. Similarly columns 1214 and 1216display the impact on the memory of the target machine. Memory loadvalues from the source server are normalized to the size of the memoryon the target server. This display allows a user to quickly determine ifthe consolidation of the source server to the target server keeps thetarget server within utilization targets and also provides an indicationof how many additional DLLs will need to be loaded onto the targetserver to support the applications moved from the source server.

In addition to system compatibility, process compatibility is animportant consideration in determining which servers to consolidate.When the Process compatibility detail choice 1106 is made in pane 1100of FIG. 11, the source system processes list box 1112 is enabled, andthe user chooses one or more of the processes. The user then chooses asingle target server from the Target Systems list box 1110. FIG. 13provides a UI that displays the result of the process analysis andassists a user in determining process compatibility. Window 1300displays a comparison of common DLL compatibility and differences on thesource and target server. Column 1302 displays the common DLL name,column 1204 displays its version and column 1306 indicates whether thatcolumn is present (“1”) or absent (“0”) on the target server. Moreover,even if the DLL is present on the target server, column 1308 providesand indication of whether the versions on the source and the target arethe same (“1”) or different (“0”). When the version of the DLL on thetarget system is different, column 1310 contains the version that wasfound on the target system. As is illustrated in here, many of the DLLson the source are also present on the target server; however, the targetversion does not match the source version. Columns 1304 and 1310 providethe version of the source and the target DLL versions, respectively. Inthis way, a user can quickly determine whether the target version is anewer version of the DLL, perhaps alleviating the need to update.

FIGS. 14 and 15 provide many of the same analysis tools as thoseprovided above in the context of database consolidation. In addition toconsolidating applications and processes on servers, databaseconsolidation is also an important aspect of consolidation. Databaseconsolidation requires an understanding of how database schemas varyamong databases or database instances on various servers. Moreparticularly, database consolidation may be available by the recognitionthat multiple database, while not identical, may have enough informationin common that can be combined. This commonality requires, at leastinitially, that the target database have all of the columns in thesource database or a sufficient number of columns of the source databaseand the ability to add columns and or table from the source database.Thereafter, addition needs can be addressed such as moving triggers,stored procedures, alerts and the like to the target database.

FIG. 14 provides a high level view of the common SQL server logins. Inthis example, window 1400 is divided into two panes 1402 and 1404. Pane1402 provides a listing of database inventory that was collected for theservers during discovery as indicated above. Pane 1404 list all of thecommon SQL Logins that were discovered on the multiple servers for thedatabases the servers in the server farm, e.g., 110. Column 1406provides the login name for the databases. Column 1408 provides theinstance name. Hence a user can easily determine which databases withcommon login names are on which servers.

When the database Compatibility details choice 1114 is made in pane 1100of FIG. 11, the user can perform database compatibility analysis. FIG.15 provides additional information necessary to analyze databasecompatibility. In this example, window 1500 provides two panes 1502 and1504. Pane 1502 is identical to pane 1402. Pane 1504 provides a listingof table and column names and provides an indication of schemacommonality and differences. Column 1508 provides a listing of tablenames and columns names for the tables in question. Column 1506 providesan item type that identifies whether the item listed in column 1508 is adatabase table or database column. Column 1510 provides an indicationwhether the item in column 1508 is present on (“1”) or absent from (“0”)the target server. Column 1512 provides an indication whether the itemson the source and the target are compatible (“1”), incompatible (“0”),or whether that cannot be determined (“???”).

FIG. 16A and 16B provide further details on the implementation of theanalysis tools described above. In particular, the selected XML filesfor the selected system and database inventory are loaded into database206 (See FIG. 2). SQL queries are then run against the data in thedatabase to perform the analysis, i.e., to compare inventory in oneserver with the inventory in another server. FIG. 16A provides a highlevel view of a schema 206 a that could be used to store the collectedXML data. The schema illustrates the kind of tables that could be used.The XML data could be loaded in the SQL database according to knowtechniques such as XML Bulk Load or other SQLXML commands.

Preferably, a more flexible approach would be used. In such animplementation, an XML loader uses Microsoft XMLParser to parse the XMLcontents into datasets. The datasets are then used to build relationalrecords and stored into a relational database, e.g., database 206.

Schema 206 a contains Sysinfo table 1602 which contains information suchas the system name, make, and model number, system memory information,as well as information about the source of the data, i.e., which XMLfile and version number. HardwareInfo table 1604 contains serverhardware information such as number of processors and availableprocessors. Network table 1608 contains a variety of network informationsuch as NIC identifiers, IP addresses, and so on. Device table 1610contains information on hardware devices such as device names. Drivetable 1606 contains server drive information such as total byte storage,bytes free, volume name, and so on. Application table 1612 containsinformation such as application name and version number. Process table1614 contains information on processes such as process owner, cpuutilization information, memory utilization information, and so on.Module table 1618 contains module information such as module size,module name, and so on. Process Module Association table 1616 associatesmodules with parent processes.

Schema 206 a is useful in performing system inventory analysis for suchthings as application consolidation. With respect to database analysis,FIG. 16B illustrates an high level schema for use with the databaseinventory XML files. As such, selected database XML files that werediscovered from the various servers as described above are loaded intodatabase 206 in accordance with schema 206 b. Server table 206 keeps theinformation identifying which server maintains the discovered database.Instance table 1622 keeps information on the names of one or moreinstances of database servers installed on the server, e.g., SQL Server6.0 and SQL Server 7.0. For each instance, database table 1624 containsinformation on one or more databases within that instance. For eachdatabase in table 1624, Table table 1626 has all of the table names andColumn table 1628 maintains all of the columns for a given table.Procedure table 1632 maintains information such as the names of storedprocedures used in a database. Function table 1636 maintains a list offunction names associated with a database. Trigger table 1640 maintainsa list of trigger names associated with a database. DBRole table 1644maintains a list of database roles associated with a database.Additionally, for each instance in Instance table 1622, DTSPackage tablemaintains information related to the data transformation servicespackages associated with that database such as the name of the packageand the owner. Login table 1638 maintains login information such as username. Finally, Server Role table 1642 maintains information related tothe server role such as member name and member SID.

After the analysis has been completed and consolidation candidates havebeen identified, there may be a significant number of files that have tomoved and/or loaded on the target server. FIGS. 17 and 18 illustrateaspects of the subject system that assist in automating at least aspectsof the deployment of the new assets to a target server. FIG. 17 providesan example asset deployment UI. Window 1700 has drop down box 1702wherein deployment tool has been selected. Select box 1708 provides amechanism for a user to identify a target server to which assets are tobe deployed. Pane 1706 identifies all of the various assets to bedeployed on the target server. Notably, box 1704 provides a user withthe capability to define deployment rules to be used in association withthe deployment of assets on the target server.

After a user has determined that deployment rules should be used,selecting define button 1705 causes a rules editor to launch. FIG. 8further illustrates the rules editor. Window 1800 provides an examplelisting of predefined rules templates including the following template:

Check for minimum disk space on a drive;

Check for minimum memory (RAM);

Check for minimum number of processors;

Check if a copy of this application is already installed;

Make sure that a conflicting application is NOT installed;

Make sure that a required application is already installed.

Of course other rule templates could be defined without departing fromthe scope of this aspect of the subject system.

FIG. 19 further illustrates aspects of the deployment system. Here,consolidation information has been collected and analyzed, as describedherein above. Thereafter, the consolidated server farm 120 is to bedeployed. To that end, all of the executables, binaries, and essentiallyall of the files necessary to perform an installation are placed into afolder with a setup file. Typically this will be a single applicationper folder but need not be so limited. Additionally, the templates areselected for the deployment. For example, if minimum memory is selected,then a user will define the minimum memory requirements, e.g., 512 MB.Similarly parameters are defined for other selected templates, e.g., 2processors, 1 gigabytes of disk space, and so on. At some point, thetarget servers are selected for deployment. As illustrated in FIG. 19,servers 120 a and 120 b were selected. Alternatively an entire domainmay be selected. As described above in connection with the discoveryaspects of the system, the assets of the target systems are discovered.This could have been performed as part of the initial consolidationprocess or could be performed independently.

The relevant XML files containing the discovered information is thenparsed and compared to the defined rules. If the rules pass, the filesare transmitted to the target server or servers and the installation anda remote procedure call is made to start the installation. Preferably,the transmitted install files are compressed before transmitting anddecompressed on the target. Preferably the compression is performed byZIPPING the configuration files before transmission and unZIPPING theconfiguration folders at the target server. The unzip program may besent as part of the process, for example, by bundling the unzip programas a self extracting file.

Preferably, the testing of the defined rules is performed by an XPATHquery against the XML file. For example, using the example XML filedefined above in connection with the discovery, an XPATH query for thenumber of processors would return a “2” if applied against the below XMLexcerpt: <PE_HdweInfo ID=“HI” parent_ID=“5008DJUL1030-SI”numberOfProcessors=“2” availableProcessorMask=“3” processorLevel=“15”processorRevision=“521”>  <PE_ProcessorSpeed parent_ID=“HI” procNum=“0”speed=“2992” />  <PE_ProcessorSpeed parent_ID=“HI” procNum=“1”speed=“2992” /> <PE_Device parent_ID=“HI” deviceLocation=“LPT1”cmpLocation=“”>  <deviceName>Printer Port Logical Interface</deviceName> </PE_Device> <PE_Device parent_ID=“HI” deviceLocation=“USB Device”cmpLocation=“”>  <deviceName>ViewSonic Color Pocket PC V37</deviceName> </PE_Device> <PE_Device parent_ID=“HI” deviceLocation=“”cmpLocation=“0,0,0,1”>  <deviceName>HL-DT-ST RW/DVDGCC-4480B</deviceName>  </PE_Device> ...

Similar XPATH queries could be applied for other rule values.

The above deployment may be used in contexts other than theconsolidation context. For example, a company may want to deploy anapplication across a number of client machines throughout itsorganization. The above technique would allow a single deployment setupto automatically install the applications on the selected machines thatmeet the defined rules.

The above consolidation in an example description only and is notintended to indicate that applications and databases are consolidated inall server consolidations. Rather, the example is intended to indicatethe breath of consolidation that may be possible. The overarching themeis that consolidation 115 provides the tools to determine the inventoryof hardware, software, and data on a server farm such as server farm 110and simplify the consolidation of that hardware, software and data.

Elements of embodiments of the invention described below may beimplemented by hardware, firmware, software or any combination thereof.The term hardware generally refers to an element having a physicalstructure such as electronic, electromagnetic, optical, electro-optical,mechanical, electro-mechanical parts, while the term software generallyrefers to a logical structure, a method, a procedure, a program, aroutine, a process, an algorithm, a formula, a function, an expression,and the like. The term firmware generally refers to a logical structure,a method, a procedure, a program, a routine, a process, an algorithm, aformula, a function, an expression, and the like that is implemented orembodied in a hardware structure (e.g., flash memory, ROM, EROM).Examples of firmware may include microcode, writable control store, andmicro-programmed structure. When implemented in software or firmware,the elements of an embodiment of the present invention are essentiallythe code segments to perform the necessary tasks. The software/firmwaremay include the actual code to carry out the operations described in oneembodiment of the invention, or code that emulates or simulates theoperations. The program or code segments can be stored in a processor ormachine accessible medium or transmitted by a computer data signalembodied in a carrier wave, or a signal modulated by a carrier, over atransmission medium. The “processor readable or accessible medium” or“machine readable or accessible medium” may include any medium that canstore, transmit, or transfer information. Examples of the processorreadable or machine accessible medium include an electronic circuit, asemiconductor memory device, a read only memory (ROM), a flash memory,an erasable ROM (EROM), a floppy diskette, a compact disk (CD) ROM, anoptical disk, a hard disk, a fiber optic medium, a radio frequency (RF)link, and the like. The computer data signal may include any signal thatcan propagate over a transmission medium such as electronic networkchannels, optical fibers, air, electromagnetic, RP links, etc. The codesegments may be downloaded via computer networks such as the Internet,Intranet, etc. The machine accessible medium may be embodied in anarticle of manufacture. The machine accessible medium may include datathat, when accessed by a machine, cause the machine to perform theoperations described in the following. The machine accessible medium mayalso include program code embedded therein. The program code may includemachine readable code to perform the operations described in thefollowing. The term “data” here refers to any type of information thatis encoded for machine-readable purposes. Therefore, it may includeprograms, code, data, files, and the like.

All or part of an embodiment of the invention may be implemented byhardware, software, or firmware, or any combination thereof. Thehardware, software, or firmware element may have several modules coupledto one another. A hardware module is coupled to another module bymechanical, electrical, optical, electromagnetic or any physicalconnections. A software module is coupled to another module by afunction, procedure, method, subprogram, or subroutine call, a jump, alink, a parameter, variable, and argument passing, a function return,and the like. A software module is coupled to another module to receivevariables, parameters, arguments, pointers, etc. and/or to generate orpass results, updated variables, pointers, and the like. A firmwaremodule is coupled to another module by any combination of hardware andsoftware coupling methods above. A hardware, software, or firmwaremodule may be coupled to any one of another hardware, software, orfirmware module. A module may also be a software driver or interface tointeract with the operating system running on the platform. A module mayalso be a hardware driver to configure, set up, initialize, send andreceive data to and from a hardware device. An apparatus may include anycombination of hardware, software, and firmware modules.

Embodiments of the invention may be described as a process which isusually, depicted as a flowchart, a flow diagram, a structure diagram,or a block diagram. Although a flowchart may describe the operations asa sequential process, many of the operations can be performed inparallel or concurrently. In addition, the order of the operations maybe re-arranged. A process is terminated when its operations arecompleted.

Those skilled in the art also will readily appreciate that manyadditional modifications are possible in the exemplary embodimentwithout materially departing from the novel teachings and advantages ofthe invention. Any such modifications are intended to be included withinthe scope of this invention as defined by the following exemplaryclaims.

1. A method for deploying computing components, comprising: receivingover a network a first data set from a first computing device, saidfirst data set indicative of characteristics of the at least onecomputing device: comparing characteristics of the at least onecomputing device to a set of predefined characteristic constraints; andtransmitting a component to said at least one computing device forinstallation if said characteristics meet the predefined characteristicconstraints.
 2. The method as recited in claim 1 comprising: receivingover a network at least a second data set indicative of characteristicsof at least a second computing device; comparing characteristics of theat least a second computing device to the set of predefinedcharacteristics constraints; and transmitting a component to the atleast a second computing device for installation if said characteristicsmeet the predefined characteristic constraints.
 3. The method as recitedin claim 1 wherein the characteristic constraint comprises at least oneof: minimum disk space on a drive, minimum memory, minimum number ofprocessors, application not already installed, a conflicting applicationis not installed, a required application is already installed.
 4. Themethod as recited in claim 1 wherein the data set is received in amarkup language.
 5. The method as recited in claim 4 wherein the markuplanguage is XML.
 6. The method as recited in claim 3 wherein the act ofcomparing comprises performing an XPATH query on the data set toretrieve a predetermined characteristic and comparing the retrievedvalue of the constraint to a value set by a user.
 7. The method of claim1 further comprising transmitting an agent to the first computing deviceto generate the first data set.
 8. The method as recited in claim 1comprising issuing a remote procedure call to begin installation of thecomponent.
 9. The method as recited in claim 1 wherein the componentcomprises an application program.
 10. The method as recited in claim 1comprising compressing the component before the act of transmitting. 11.The method as recited in claim 10 comprising appending a decompressionprogram with the component.
 12. A system for deploying computingcomponents, comprising: a communication device for receiving a firstdata set of characteristics of at least one computing device; aprocessor in communication with a memory device comprisingcomputer-executable instructions capable of comparing characteristics ofthe at least one computing device to a set of predefined characteristicconstraints, and a communication device for transmitting a component tosaid at least one computing device for installation if saidcharacteristics meet the predefined characteristic constraints.
 13. Thesystem as recited in claim 12 comprising: a communication device forreceiving at least a second data set from the discovery agent indicativeof characteristics of at least a second computing device; a processor incommunication with a memory device comprising computer-executableinstructions capable of comparing characteristics of the at least asecond computing device to the set of predefined characteristicsconstraints; and a communication device for transmitting a component tothe at least a second computing device for installation id saidcharacteristics meet the predefined characteristic constraints.
 14. Thesystem as recited in claim 13 wherein the characteristic constraintcomprises at least one of: minimum disk space on a drive, minimummemory, minimum number of processors, application not already installed,a conflicting application is not installed, a required application isalready installed.
 15. The system as recited in claim 12 wherein thedata set is received in a markup language.
 16. The system as recited inclaim 15 wherein the markup language is XML.
 17. The system as recitedin claim 14 wherein the computer-readable instructions capable ofcomparing comprise computer readable instructions for performing anXPATH query on the data set to retrieve a predetermined characteristicand comparing the retrieved value of the constraint to a value set by auser.
 18. The system as recited in claim 12 further comprising a memorydevice coupled to the processor comprising computer-readableinstructions capable of issuing a remote procedure call to begininstallation of the component.
 19. The system as recited in claim 12wherein the component comprises an application program.
 20. The systemas recited in claim 12 comprising a memory device coupled to theprocessor comprising computer-readable instructions capable ofcompressing the component before the act of transmitting.
 21. The systemas recited in claim 20 comprising computer-readable code appended to thecomponent bearing instructions for decompressing the component.